If you want to get better at something you need to know what areas to improve on. Most developers will have a list in mind of the new technologies or techniques they want to spend more time on to improve on, but what about the day to day things you work on. The first is to measure, to get stats on some of the areas you work on.
It’s similar to an athlete. Stats are collected in abundance these days for professional athletes and examined in detail to try to achieve marginal gains that will make them become better. So why should they have all the fun.
So what are some of the areas you should look at? In this blog post we’ll start with predictability.
Predictability
Ask a manager what they want from their team when it comes to delivering a product and most will say they want the product to do what its meant to do, and they want it done on time. Hopefully managers will care about other metrics like code quality and maintainable, but at the end of the day they want the latest feature on time and working.How often as a developer are you asked ‘How long will it take to deliver this feature?’.
Sometimes its straight forward as you worked on a similar feature recently and you have a good idea how long it took you. But do you really know how long it took you?
Or you may feel there are too many unknowns about this new feature and all you can hope for is an educated guess.
The first step is to know how accurately you can estimate work, both the type of tasks you are confident estimating and the tasks with all those mysterious unknowns. The first step is to collect those stats. If you use a task tracking software like Jira or FogBugz you are already halfway there. If not you can use something like Excel. It doesn’t really matter what you use, as long as you record the data using something that works for you.
Every time you have to estimate a new piece of work, record the following:
Date This is the date you made the estimate. This will allow you to track you estimates over a period of time. Hopefully as you improve your estimates, you will get better and you can disregard your older estimates. It will also allow you to see how your estimates have (hopefully) improved over time, and will provide good evidence at your next review.
How long you think it will take This is your initial estimate before you start any work on how long you think it will take to do. To make things easier to analyse later always use the same timescales, either hours or days. Don’t use a combination of hours and days.
For an individual task I would never try to break it down to anything less the 30 minutes. Even the smallest of typos can take longer than you think to fix, by the time you…
- read the bug ticket...
- spoken to the person how raised it as its not clear from their description where the typo is...
- located the content to update (is it in the code, a resource file or coming from the database)...
- updated the typo...
- spun up the software with the fix to confirm you have actually fixed it...
- checked the code back in...
- updated the bug ticket...
How long it actually took So how long did it take you to complete the task? Try to be as honest as possible, but don’t worry about being accurate to the nearest minute. If you use a system like Jira you may be logging the time spent on the task anyway.
How confident you feel about the estimate This could be on a scale of 1 to 5, and allows you to give an indication on how confident you feel about your initial estimate. If it has a lot of unknowns, the requirements are vague or it involves an area of the product or technology you are unfamiliar with, you would want to give this a low confidence level.By including this confidence level you will be able to see how accurate you are at estimating something when you think you know what it entails and are confident. And ti will also show how accurate you are at estimating something with a lot of unknowns. You may be surprised to find that over confidence in estimating may lead to poorer estimates.
Task category This is to categories the type of work you will be doing. This will be very much based on your own circumstances. It could be divided into the area of the technology stack (front end, business layer etc), or the functional area of the product (login, user admin, reporting etc), or even a combination.
Description This is a brief description of the work, or a link back to more details (e.g. the work request number).
Accuracy The final step is to work out the percentage difference between your initial estimate and the actual time it took to complete:
- You will be able to see how well you are at estimating certain types of work (e.g. a change to an API which you have a low level of confidence with estimating).
- Based on the historical estimates you may find that the average difference between your initial estimate and your actual time taken is 110% for a particular type of task. This means you tend to underestimated this type of work by 10%.
- Or you may decide to think of it as a range, and your estimates for this type of work are between 80% and 140%.
- If you are given a new piece of work you can look at your pass trends and take this into account when estimating, so you can refine your thoughts. Or you can present your estimates with a range, based on your past percentage accuracy. For example if you had a piece of work that your estimated to be 5 days, but in the past you tend to underestimate this by type of work by 30%, you could say 'This piece of work has a lot of unknowns and I think it will take between 5 days and 6.5 days to complete'.
- You can see how the accuracy of estimates changes over time. Are you getting better or worse? And you may decide to remove older stats as you improve.
A couple of additional considerations:
Are you just estimating the initial development work or are you taking into account design, testing, feedback from testing, deployment, documentation, meetings etc? In some ways it doesn’t matter to much as long as its clear what your estimates include and that you are consistent with what they include.
What about interruptions? if you know a piece of work will take 4 hours without interruptions do you estimate 4 hours. Or if you know in a given day that you get interrupted by meetings, questions from other teams etc, do you factor these in as well? Do you make you estimate 4 hours for the work and an additional hour for all the likely interruptions?
Again it doesn’t matter as long as you are clear what the estimate includes and you are consistent. It will probably depend on your particular work environment, how many interruptions you tend to get and if your project manager already includes these types of unknowns. In the past I used to give estimates without the interruptions, but these days I prefer to be more realistic.
In a future post we’ll look at how we can use stats to improve other areas of your work.
